Method and Apparatus for Transferring Data Between IP Network Devices and SCSI and Fibre Channel Devices Over an IP Network

ABSTRACT

A method and apparatus for transferring data between IP devices (including, but not limited to, Gigabit Ethernet devices) and SCSI or Fibre Channel devices. The device interfaces may be either SCSI, Fibre Channel or IP interfaces such as Gigabit Ethernet. Data is switched between SCSI and IP, Fibre Channel and IP, or between SCSI and Fibre Channel. Data can also be switched from SCSI to SCSI, IP to IP and FC to FC. The port interfaces provide the conversion from the input frame format to an internal frame format, which can be routed within the apparatus. The amount of processing performed by each port interface is dependent on the interface type. The processing capabilities of the present invention permit rapid transfer of information packets between multiple interfaces at latency levels meeting the stringent requirements for storage protocols. The configuration control can be applied to each port on a switch and, in turn, each switch on the network, via an SNMP or Web-based interface, providing a flexible, programmable control for the apparatus.

CROSS REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.10/138,029 filed 30 Apr. 2002 entitled “Method and apparatus fortransferring data between IP network devices and SCSI and fibre channeldevices over an IP network,” which is a continuation of U.S. Pat. No.6,400,730, also entitled “Method and apparatus for transferring databetween IP network devices and SCSI and fibre channel devices over an IPnetwork,” which claims the benefit of priority pursuant to U.S.C.§119(e) of U.S. provisional application No. 60/123,606 filed 10 Mar.1999 also entitled “Method and apparatus for transferring data betweenIP network devices and SCSI and fibre channel devices over an IPnetwork,” which are all hereby incorporated by reference as though fullyset forth herein.

BACKGROUND OF THE INVENTION

The present invention relates to transferring information betweenstorage devices and a network via a switched, packetized communicationssystem. In particular, the present invention relates to methods andapparatus for receiving, translating, and routing data packets betweenSCSI (Small Computer Systems Interface), Fibre Channel and Ethernetdevices in a flexible, programmable manner.

In enterprise computing environments, it is desirable and beneficial tohave multiple servers able to directly access multiple storage devicesto support high-bandwidth data transfers, system expansion, modularity,configuration flexibility and optimization of resources. In conventionalcomputing environments, such access is typically provided via filesystem level Local Area Network (LAN) connections, which operate at afraction of the speed of direct storage connections. As such, access tostorage systems is highly susceptible to bottlenecks.

Storage Area Networks (SANs) have been proposed as one method of solvingthis storage access bottleneck problem. By applying the networkingparadigm to storage devices, SANs enable increased connectivity andbandwidth, sharing of resources, and configuration flexibility. Thecurrent SAN paradigm assumes that the entire network is constructedusing Fibre Channel switches. Therefore, most solutions involving SANsrequire implementation of separate networks: one to support the normalLAN and another to support the SAN. The installation of new equipmentand technology, such as new equipment at the storage device level (FibreChannel interfaces), the host/server level (Fibre Channel adapter cards)and the transport level (Fibre Channel hubs, switches and routers), intoa mission-critical enterprise computing environment could be describedas less than desirable for data center managers, as it involvesreplication of network infrastructure, new technologies (i.e., FibreChannel), and new training for personnel. Most companies have alreadyinvested significant amounts of money constructing and maintaining theirnetwork (e.g., based on Ethernet and/or ATM). Construction of a secondhigh-speed network based on a different technology is a significantimpediment to the proliferation of SANs. Therefore, a need exists for amethod and apparatus that can alleviate problems with access to storagedevices by multiple hosts, while retaining current equipment and networkinfrastructures, and minimizing the need for new training for datacenter personnel.

In general, a majority of storage devices currently use “parallel” SCSIor Fibre Channel data transfer protocols whereas most LANs use anEthernet protocol, such as Gigabit Ethernet. SCSI, Fibre Channel andEthernet are protocols for data transfer, each of which uses a differentindividual format for data transfer. For example, SCSI commands weredesigned to be implemented over a parallel bus architecture andtherefore are not packetized. Fibre Channel, like Ethernet, uses aserial interface with data transferred in packets. However, the physicalinterface and frame formats between Fibre Channel and Ethernet are notcompatible. Gigabit Ethernet was designed to be compatible with existingEthernet infrastructures and is therefore based on an Ethernet packetarchitecture. Because of these differences there is a need for newmethods and apparatus to allow efficient communication between theseprotocols.

SUMMARY OF THE INVENTION

The present invention solves the above and other problems, therebyadvancing the state of the useful arts, by providing methods andapparatus for transferring data between storage device interfaces andnetwork interfaces. In particular, the present invention bringssophisticated SAN capabilities to existing enterprise computingconfigurations, without the installation of costly Fibre Channelswitches and hubs, by providing the means for Internet Protocol (IP)devices to transparently communicate with SCSI and Fibre Channel devicesover an IP network. The present invention accomplishes this through theuse of Fibre Channel Protocol (FCP), an industry standard developed forimplementation of SCSI commands over a Fibre Channel network. Theinvention allows the storage devices to retain the use of standard SCSIand Fibre Channel storage interfaces and construct a SAN using acompany's existing network infrastructure. Therefore, no changes arerequired in host bus adapters (HBA) or storage devices (e.g. diskdrives, tape drives, etc).

According to the present invention, methods and apparatus are providedfor transferring data between IP devices (including, but not limited to,Gigabit Ethernet devices) and SCSI or Fibre Channel devices. The deviceinterfaces may be either SCSI, Fibre Channel or IP interfaces such asGigabit Ethernet. Data is switched between SCSI and IP, Fibre Channeland IP, or between SCSI and Fibre Channel. Data can also be switchedfrom SCSI to SCSI, Fibre Channel to Fibre Channel and IP to IP. The portinterfaces provide the conversion from the input frame format to aninternal frame format, which can be routed within the apparatus. Theapparatus may include any number of total ports. The amount ofprocessing performed by each port interface is dependent on theinterface type. The processing capabilities of the present inventionpermit rapid transfer of information packets between multiple interfacesat latency levels meeting the stringent requirements for storageprotocols. The configuration control can be applied to each port on aswitch and, in turn, each switch on the network, via an SNMP orWeb-based interface, providing a flexible, programmable control for theapparatus.

According to one aspect of the present invention, a method is providedfor routing data packets in a switch device in a network such as a SAN.The method typically comprises the steps of receiving a packet from afirst network device at a first port interface of the switch device,wherein the packet is one of a SCSI formatted packet (i.e., SCSIformatted data stream converted into a packet), a Fibre Channel (FC)formatted packet and an Internet protocol (IP) formatted packet, whereinthe first port interface is communicably coupled to the first networkdevice, and converting the received packet into a packet having aninternal format. The method also typically includes the steps of routingthe internal format packet to a second port interface of the switchdevice, reconverting the internal format packet to one of a SCSIformatted packet, an FC formatted packet or an IP formatted packet, andtransmitting the reconverted packet to a second network devicecommunicably coupled to the second port interface.

According to another aspect of the present invention, a network switchdevice is provided which typically comprises a first port interfaceincluding a means for receiving data packets from a network device,wherein the receiving means receives one of a SCSI formatted packet anda Fibre Channel (FC) formatted packet from a first network device, and ameans for converting received packets into packets having an internalformat, wherein the received data packet is converted into a firstpacket having the internal format. The switch device also typicallycomprises a second port interface including a means for reconvertingpackets from the internal format to an IP format, wherein the firstpacket is converted into a packet having an IP format, and a means fortransmitting IP packets to a network, wherein the IP formatted packet istransmitted to an IP network. A means for routing the first packet tothe second port interface is also provided.

According to yet another aspect of the present invention, a networkswitch device is provided which typically comprises a first portinterface including a means for receiving data packets from an IPnetwork, wherein the first interface means receives a packet in an IPformat, and a means for converting received packets into packets havingan internal format, wherein the received packet is converted into afirst packet having an internal format. The switch device also typicallycomprises a second port interface including a means for reconvertingpackets having the internal format to packets having the SCSI format,and a means for transmitting reconverted packets to a SCSI networkdevice. The switch device further typically includes a third portinterface having a means for reconverting packets having the internalformat to packets having the FC format, and a means for transmittingreconverted packets to a FC network device. A means for routing packetsbetween the first, second and third port interfaces is also typicallyprovided. In operation, wherein if the first packet is routed to thesecond port interface, the first packet is converted to the SCSI formatand transmitted to the SCSI network device, and wherein if the firstpacket is routed to the third port interface, the first packet isconverted to the FC format and transmitted to the FC network device.

According to a further aspect of the present invention, a network switchdevice is provided for use in a storage area network (SAN). The switchdevice typically comprises a first port interface communicably coupledto a SCSI device, wherein the first port interface converts SCSIformatted data packets received from the SCSI device into data packetshaving an internal format, and wherein the first port interface convertsdata packets having the internal format into SCSI formatted datapackets. The switch device also typically comprises a second portinterface communicably coupled to a FC device, wherein the second portinterface converts FC formatted data packets received from the FC deviceinto data packets having the internal format, and wherein the secondport interface converts data packets having the internal format into FCformatted data packets. The switch device further typically includes athird port interface communicably coupled to a IP device, wherein thethird port interface converts IP formatted data packets received fromthe IP device into data packets having the internal format, and whereinthe third port interface converts data packets having the internalformat into IP formatted data packets, and a switch fabric for routingdata packets having the internal format between the first, second andthird port interfaces. In typical operation, when a first one of theSCSI, FC and IP devices sends a first data packet to a second one of theSCSI, FC and IP devices, the port interface coupled to the first deviceconverts the first data packet to a packet having the internal formatand routes the internal format packet through the switch fabric to theport interface coupled to the second device, wherein the port interfacecoupled to the second device reconverts the internal format packet intothe format associated with the second device and sends the reconvertedpacket to the second device.

According to yet a further aspect of the present invention, a networkswitch device for use in a storage area network (SAN) is provided. Theswitch may comprise any combination of Fibre Channel, SCSI, Ethernet andInfiniband ports, and may comprise any number of total ports. The switchdevice typically comprises a first port interface communicably coupledto one of a SCSI device(s), an FC device, or an IP device, a second portinterface, wherein the second port interface is configurable tocommunicate with either a FC device or an Ethernet device, and a switchfabric for routing data packets having the internal format between thefirst and second port interfaces. In typical operation, when the secondport interface is configured to communicate with a FC device, the secondport interface converts FC formatted data packets received from the FCdevice into data packets having an internal format, and wherein thesecond port interface converts data packets having the internal formatreceived from the switch fabric into FC formatted data packets, andwherein when the second port interface is configured to communicate withan Ethernet device, the second port interface converts Ethernetformatted data packets received from the Ethernet device into datapackets having the internal format, and wherein the second portinterface converts data packets having the internal format received fromthe switch fabric into Ethernet formatted data packets. The second portinterface can be either self-configurable or user configurable.

Reference to the remaining portions of the specification, including thedrawings and claims, will realize other features and advantages of thepresent invention. Further features and advantages of the presentinvention, as well as the structure and operation of various embodimentsof the present invention, are described in detail below with respect tothe accompanying drawings. In the drawings, like reference numbersindicate identical or functionally similar elements.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an example of a SAN constructed according to thepresent invention;

FIG. 2 is a block diagram of an overview of the Storage over InternetProtocol (SoIP) implementation;

FIG. 3 illustrates the required protocol conversion steps between FibreChannel, SCSI and IP devices in the apparatus switch fabric according toan embodiment of the present invention;

FIG. 4 is an overview of the legacy storage protocol conversion methodby which the functionality of the invention is achieved;

FIG. 5 is a high level switch diagram outlining the basic architectureof the physical apparatus according to an embodiment of the presentinvention;

FIGS. 6 a-c illustrate FCP packet encapsulation according to anembodiment of the present invention;

FIG. 7 shows the frame flow for the “session” initialization for FibreChannel devices connected to an SoIP network;

FIGS. 8 and 9 show the flow of data frames for a node login initiated byFC port A of switch 1 to FC Port B of switch 2 located remotelyaccording to an embodiment of the present invention;

FIG. 10 shows the routing of Port Login Request and Response frames forlocal FC ports according to an embodiment of the present invention;

FIG. 11 shows an example of the address domains which exist in a networkaccording to one embodiment of the present invention;

FIGS. 12 a-d illustrate a network architecture and address tables for aThird Party Command example;

FIG. 13 illustrates layer 2 FCP packet encapsulation according to anembodiment of the present invention;

FIGS. 14 a-c illustrate examples of UDP Frame demultiplexing accordingto embodiments of the present invention;

FIG. 15 is a high level block diagram which illustrates the basicarchitecture for a switch port that supports both Fibre Channel andEthernet according to an embodiment of the present invention;

FIG. 16 is a high level block diagram which illustrates the basicarchitecture for a switch port that supports both Fibre Channel andEthernet, where two routing blocks are combined into a single blockaccording to an embodiment of the present invention;

FIG. 17 is a high level block diagram which illustrates the basicarchitecture for a switch port that supports both Fibre Channel andEthernet wherein low-level port interface logic blocks are combinedaccording to an embodiment of the present invention;

FIG. 18 is a high level block diagram which illustrates the basicarchitecture for a switch port that supports both Fibre Channel andEthernet using a Field Programmable Gate Array (FPGA) according to anembodiment of the present invention;

FIG. 19 shows a block diagram of a common FC/Gigabit Ethernet portcombined with a GBIC interface according to an embodiment of the presentinvention; and

FIG. 20 illustrates the architecture of an intelligent network interfacecard (NIC) according to an embodiment of the present invention.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

FIG. 1 illustrates an example of a storage area network (SAN) 10according to an embodiment of the present invention. As shown, network10 includes numerous storage devices, such as tape libraries 15, RAIDdrives 20 and optical drives 25 (e.g., CD, DVD, etc.) and servers 30.The storage devices can be either storage targets (e.g., tape libraries15, RAID drives 20, etc.) or initiators (e.g., servers 30). Note that adevice could be both an initiator and a target. In a preferredembodiment, the invention is implemented in a switching device 35 withinnetwork 10. For example, as shown in FIG. 1, each switching device 35 isan “edge” switch which provides the connectivity between nodes (i.e.,one or more storage devices) and a network 40. In other words, theswitch resides on the “edge” of the network where the devices arelocated. Each edge switch 35 allows connected storage elements tocommunicate through the edge switch with no traffic being sent tonetwork 40. Each edge switch 35 also allows storage elements connectedto different edge switches to communicate with each other throughnetwork 40. In a preferred embodiment, network 40 is an Ethernetnetwork, but other networks may be used, for example, AsynchronousTransfer Mode (ATM)-based or FDDI-based networks, or the like.

In one embodiment, a switching device 35 is implemented in an SoIP(Storage over Internet Protocol) storage area network (SAN) as shown inFIG. 2. According to the present invention, SoIP is a framework fortransporting SCSI commands and data over IP networks using the FibreChannel Protocol for SCSI (FCP) for communication between IP networkedstorage devices. A majority of storage devices currently communicateusing either a “parallel” SCSI bus or a Fibre Channel serial interface.FCP is an FC-4 Upper Layer Protocol for sending SCSI commands and dataover a Fibre Channel network yielding a “serial” SCSI network. The SoIPframework enables FCP for use on an IP network by defining the SoIPprotocol. Storage devices and host bus adapters operating the SoIPprotocol form a storage area network (SAN) directly on an IP network.This framework offers an enormous advantage in the installation andutility of SANs.

As shown in FIG. 2, each SoIP device 50 converts SCSI commands and datainto FCP data frames in FCP block 52. The SoIP protocol layer block 54then encapsulates these FCP frames in multiple IP packets using eitherthe User Datagram Protocol (UDP) or Transport Control Protocol (TCP). IPport 56 forwards the packet to IP network 60, which routes the IPpackets between the devices 50 or to switch 35. IP network 60 ispreferably an Ethernet network, but may be based on any IP-compatiblemedia including ATM, FDDI, SONET and the like. The storage name server65 serves as a database where devices store their own information andretrieve information on other devices in the SoIP network. The SoIPproxy 70 performs protocol conversion between SoIP based on UDP and SoIPbased on TCP.

Because the majority of storage devices currently use “parallel” SCSI orFibre Channel protocols, the transition to SoIP-based SANs may behampered unless such “legacy” devices can be connected to an SoIPnetwork. For these “legacy” devices, a switch as shown in FIG. 3 isprovided for connection into an SoIP SAN.

FIG. 3 illustrates data exchange between storage devices using a switch135 according to an embodiment of the present invention. In thisembodiment, switch 135 is configured to receive data from differentinterfaces, each of which has a different data or frame format. SCSIdevice 105 transmits data using a “parallel” SCSI interface 106, FibreChannel (FC) device 110 transmits data using Fibre Channel interface 111and Ethernet device 115 transmits data using Ethernet interface 116.Switch 135 translates data received from a source port in one of thethree different formats into an internal format and transfers the datain the internal format through switch fabric 140 to a destination port.The destination port translates the data back into the native formatappropriate for the connection thereto.

In this embodiment, each device, e.g., SCSI device 105, FC device 110,Ethernet device 115, or generic IP device 120 (e.g., disk drive, tapedrive, server), performs storage operations based on the SCSI CommandSet. For Fibre Channel device 110, the SCSI commands and data areconverted to FCP and transmitted using Fibre Channel interface 111. ForSCSI device 105 the SCSI commands and data are transferred directlyusing a “parallel” bus 106. In this embodiment, the SCSI port interface125 of switch 135 acts like a SCSI to FC bridge so that the SCSI portlooks like an FC port from the point of view of switch fabric 140. Asshown, the SCSI data is preferably converted to FCP, and is not actuallytransmitted using a Fibre Channel interface. For Ethernet device 115,SCSI commands and data are converted to FCP and then encapsulated in anIP packet using UDP or TCP. The IP packet is then encapsulated in anEthernet frame and transmitted using Ethernet interface 116. Note thatthe term “SCSI device” implies a device with a “parallel SCSI bus” whilethe term “Fibre Channel device” implies a device with a Fibre Channelinterface. Both devices operate as SCSI devices at the command level.Note that SCSI device 105 does not convert the SCSI commands and data toan FCP format. Therefore, it is not possible to transfer data between FCdevice 110 and SCSI device 105 directly. As shown in FIG. 3, it ispossible for all devices connected to switch 135 to exchange data framesbecause the data format of all interfaces into switch fabric 140 are FCPcompatible frames. Also note that it is possible to replace FibreChannel with another interface. For example, FIG. 3 shows a storagedevice constructed using Ethernet in the same manner as a device isconstructed with FC. Ethernet simply replaced Fibre Channel as the mediafor transport. Infiniband may also be implemented, for example ingeneric IP device 120. As is well known, Infiniband is an I/O interfacethat merges the work of NGIO (Next Generation I/O) and Future I/O.

FIG. 4 illustrates data exchange between Fibre Channel, SCSI and IPdevices in switch apparatus 135 according to an embodiment of thepresent invention. The example in FIG. 4 is for an Ethernet based IPnetwork 160, however any other IP networks based on other protocols suchas ATM, FDDI, etc. may be used. Similar to the embodiment in FIG. 3,FIG. 4 shows the protocol translations which occur for each device. SCSIdevice 105 communicates with switch 135 using SCSI commands directlywith no encapsulation of data or commands in data frames. FC device 110uses the FCP protocol to send SCSI commands and data to switch 135.Switch 135 converts the received data to a common protocol based on FCPto allow the devices to communicate with each other. In addition, switch135 performs address translation between the Fibre Channel and SCSIaddressing schemes to the IP addressing method as will be discussed inmore detail below. This is done transparently so that no changes arerequired in Fibre Channel device 110 or SCSI device 105, or in any hostbus adapters, driver software or application software.

FIG. 5 is a high-level switch diagram outlining the basic architectureof a physical switch apparatus 235 according to an embodiment of thepresent invention. In this embodiment, switch 235 includes three mainelements: switch fabric 240, management processor 250 and portinterfaces 270. Switch fabric 240 provides a high bandwidth mechanismfor transferring data between the various port interfaces 270 as well asbetween port interfaces 270 and management processor 250. Managementprocessor 250 performs management related functions for switch 235 (e.g.switch initialization, configuration, SNMP, Fibre Channel services,etc.) primarily through management bus 255.

Port interfaces 270 convert data packets from the input frame format(e.g., parallel SCSI, FC, or Ethernet) to an internal frame format. Theinternal frame format data packets are then routed within switch fabric240 to the appropriate destination port interface. Port interfaces 270also determine how packets are routed within the switch. The amount ofprocessing performed by each port interface 270 is dependent on theinterface type. SCSI ports 270.sub.1 and 270.sub.2 provide the mostprocessing because the SCSI interface is half-duplex and it is not frameoriented. The SCSI port interfaces 270.sub.1 and 270.sub.2 also emulatethe functionality of a SCSI host and/or target. Fibre Channel ports270.sub.3 and 270.sub.4 require the least amount of processing becausethe internal frame format is most compatible with Fibre Channel. Inessence, IP ports 270.sub.5 and 270.sub.6 (e.g., Ethernet ports) andSCSI ports 270.sub.1 and 270.sub.2 convert data received into aninternal frame format before sending the packets through switch fabric240.

Because FCP frames are not directly compatible with an Ethernetinterface as they are with a Fibre Channel interface, the transmissionof FCP packets on an Ethernet interface requires that an FCP frame beencapsulated in an Ethernet frame as shown in FIG. 6 a.

FIG. 6 a illustrates FCP packet encapsulation in an IP frame carriedover an Ethernet frame according to an embodiment of the presentinvention. Field Definitions for FIG. 6 a include the following:

DA: Ethernet Destination Address (6 bytes).

SA: Ethernet Source Address (6 Bytes).

TYPE: The Ethernet packet type.

CHECKSUM PAD: An optional 2-byte field which may be used to guaranteethat the UDP checksum is correct even when a data frame beginstransmission before all of the contents are known. The CHECKSUM PAD bitin the SoIP Header indicates if this field is present.

ETHERNET CRC: Cyclic Redundancy Check (4 bytes).

As shown in FIG. 6 a, the SoIP Header field contain the followingparameters:

CLASS: This 4-bit field indicates the class of service. In oneembodiment, only the values 2 or 3 are used.

VERS: This 4-bit field indicates the protocol version of SoIP.

SoIP FLAGS: This 8-bit field contains bits that indicate variousparameters for a data frame as shown in FIG. 6 b.

In FIG. 6 a, the User Datagram Protocol (UDP) Header is the protocolused within the IP packet. TCP may also be used. The UDP header, definedin RFC 768, is 8 bytes in length consisting of four 16-bit fields asshown in FIG. 6 c, with the following field definitions:

SOURCE PORT: An optional field. When meaningful, it indicates the portof the sending process, and may be assumed to be the port to which areply should be addressed in the absence of other information. If notused, a value of zero is inserted.

DESTINATION PORT: has a meaning within the context of a particularinternet destination address.

LENGTH: the length, in bytes, of the user datagram including the UDPheader and data (thus, if there were no data in the datagram, the lengthwould be 8). For an encapsulated FCP packet, the UDP Length is the sumof the UDP Header Length, FCP Header length, and FCP Payload length andoptionally the checksum pad.

CHECKSUM: the 16-bit one's complement of the one's complement sum of apseudo header of information from the IP header, the UDP header, and thedata, padded with bytes of zero at the end (if necessary) to make amultiple of 2 bytes.

In one embodiment, a switch 235 encapsulates FC packets into an EthernetFrame with a “wrapper” around the FC information. The encapsulation ofan FCP data frame in an Ethernet packet may require that the FCP dataframe be limited in size because the maximum FCP data frame size is 2136bytes (24 byte header+2112 byte payload) whereas an Ethernet packet hasa maximum size of 1518 bytes. The use of Ethernet Jumbo Frames, whichpermit packet sizes up to 9 Kbytes to be used, eliminates the need tolimit the Fibre Channel frame size. However, support for Ethernet jumboframes is limited within the existing network infrastructure. Therefore,FCP data frames need to be limited otherwise a large FCP data frame mayneed to be “fragmented” into 2 separate Ethernet frames. The Loginprocedures defined in the Fibre Channel standard allows devices tonegotiate the maximum payload with the switch fabric 240. Thus, theswitch fabric 240 can respond to a login with a smaller payload sizethan the maximum (e.g., 1024 bytes). Switch 235 makes use of this factto limit FC packets to a size which can be encapsulated in an Ethernetpacket to eliminate the need for fragmenting FC packets. According toone embodiment, a node's maximum receive data field size is provided toswitch fabric 240 during “Fabric Login” and to each destination nodeduring “Port Login.” The fabric or node being “logged into” generates alogin response which indicates the maximum receive data field size fordata frames it is capable of receiving. Note that these values may notbe the same. For example, a fabric may have the maximum allowed size of2112 bytes while a node may limit the maximum size to 1024 bytes (e.g.the Hewlett-Packard Tachyon-Lite Fibre Channel Controller). A sourcenode may not transmit a data frame larger than the maximum frame size asdetermined for the login response.

Since an encapsulated FCP data frame cannot be larger than the maximumEthernet packet size, an upper limit is placed on the frame payload sizeduring login by a device. According to one embodiment, the upper limitvalue is set by determining or discovering the maximum IP datagram sizeand subtracting 60 bytes to account for the various headers andtrailers. For example, for an Ethernet Frame, the upper limit valueequals 1440 bytes. That is, the payload for an FCP Frame cannot exceed1440 bytes in size. This limit is established because an FCP Frame beingtransported across an IP network will not be allowed to fragment.Allowing IP datagrams to fragment degrades network performance and somost networks rarely fragment. An IP header's Do Not Fragment Flag canbe used to prevent the IP layer from fragmenting the datagram. Even withnode login setting an appropriate size for the FCP payload, this bit isset to ensure that fragmentation does not occur. According to oneembodiment, the payload is padded to a multiple of 4 bytes to make iteasy to convert frames being sent to legacy FC devices.

Each switch 235 preferably makes use of the Buffer to Buffer ReceiveData Field size to force end nodes to communicate with data frames thatwill fit within an IP packet carried over an Ethernet link. According toan embodiment of the present invention, one method for enforcing themaximum frame size is to intercept Node Login packet which can betransmitted across an Ethernet network without being fragmented.Therefore, each Management Processor may need to perform MTU (MaximumTransmission Unit) discovery to determine a size which does not resultin fragmentation of IP packets in the network.

When an FC port performs a Port Login with an FC port which is local(i.e. connected to the same switch), it is not necessary to change theBuffer to Buffer Receive Data Field Size of the Login request orresponse. This is because, in one embodiment, the switch supports themaximum frame size for transfers between FC ports (on the same switch).However, the FC port interface logic will always redirect the Port Loginpackets to the switch's Management Processor to simplify the portinterface logic. Thus, in this embodiment, the switch looks and actslike an FC switch from the point of view of any FC devices connectedthereto. An example of the routing of Port Login Request and Responseframes for local FC ports is shown in FIG. 10.

According to one embodiment, routing FC Port Login Request/Responsepackets to the Management Processor allows the Port Login for SCSI portsto be handled by the Management Processor. The Management Processoralways handles login for SCSI.

According to one embodiment, an SoIP device is uniquely identified usingtwo parameters: an IP address and an SoIP socket number. Therefore, itis possible for a device to have a unique IP address or for multipledevices to share an IP address. For example, all of the devices on aFibre Channel arbitrated loop may share an IP address while a serverHost Bus Adapter may have a dedicated IP address. In one embodiment,there are two possible modes for assignment of the SoIP socket number:local or global.

A single SoIP device connected directly to an IP network must have aunique IP address in order for the network to be able to route dataframes to the device. An IP network will not route traffic based on theSoIP socket number. However, devices connected to a switch (e.g., switch235) may share an IP address if the switch uses both the IP address andthe SoIP socket number when switching data frames.

According to the present invention, an SoIP network SAN with “legacy”Fibre Channel devices attached has different address domains due to thetwo different address methods used: IP and Fibre Channel. FIG. 11 showsan example of the address domains which exist in a network according toone embodiment of the present invention. SoIP devices communicate usingIP addresses and the SoIP socket numbers while the Fibre Channel devices(SCSI devices are treated as Fibre Channel devices by a switch) useFibre Channel addresses. Each switch 235 performs address translationbetween the IP and Fibre Channel address domains. Switch 235.sub.1performs address translation between the IP address domain and FCaddress domain 1, and Switch 235.sub.2 performs address translationbetween the IP address domain and FC address domain 2. Each switch 235assigns an IP address, SoIP socket number and Fibre Channel address toeach Fibre Channel device when the device performs a fabric login. AFibre Channel device only learns about its assigned Fibre Channeladdress. The assigned IP address, SoIP socket number and Fibre ChannelAddress are maintained within a translation table (not shown) in theswitch. Parallel SCSI devices are assigned their addresses by the switchduring initialization of the SCSI port. The Fibre Channel ports directall Name server requests by a Fibre Channel device to the managementprocessor for processing.

According to one embodiment of the present invention, the managementprocessor converts Fibre Channel Name Server requests into SoIP NameServer requests that are then forwarded to the SoIP Name Server, e.g.,implemented in server 280. In one embodiment, the SoIP name serverfunctionality is distributed and thus handled directly by the managementprocessor. Responses from the name server are returned to the managementprocessor where they are converted into Fibre Channel Name Serverresponses before being forwarded to the port that originated the nameserver request. When a Fibre Channel device sends data frames to adevice not located in its Fibre Channel address domain, switch 235converts the packet into an SoIP compatible packet. The conversionencapsulates the FCP data frame in an IP data frame as described above.Referring back to FIG. 6 a, in one embodiment, the IP addresses and SoIPsocket numbers are derived by using the Fibre Channel source address(S_ID) and the destination address (D_ID) as “keys” into the IP/FibreChannel address conversion table on the name server. The Fibre Channeladdress fields are replaced by the SoIP socket numbers when translatinga Fibre Channel data frame to an SoIP data frame. The packet is thentransmitted on the IP network and routed using the destination IPaddress. If the destination device is an SoIP compatible device, thepacket is processed directly (i.e., de-encapsulated and processed as anFCP packet) by the destination device. However, if the destination is aFibre Channel (or parallel SCSI) device, the packet is routed to aswitch 235, which receives the packet, de-encapsulates the SoIP packetand replaces the SoIP socket numbers with the appropriate source anddestination Fibre Channel addresses based on the source and destinationIP addresses and SoIP socket numbers.

According to one embodiment, local assignment is the preferred methodfor assigning SoIP socket numbers. In this embodiment, native SoIPdevices select their SoIP socket numbers while an SoIP switch (e.g.,switch 235) assigns the SoIP socket number for Fibre Channel and SCSIdevices attached to the switch. When the SoIP socket number is assignedlocally, the value chosen may be any value that results in a unique IPAddress/SoIP socket number combination. Devices that share an IP addressmust be assigned unique SoIP socket numbers in order to create a uniqueIP Address/SoIP socket number pair. Devices that have a unique IPaddress may have any desired SoIP socket number. In one embodiment, anSoIP switch assigns the SoIP socket numbers in such a manner as tosimplify the routing of received data frames. A switch must also assigna locally significant Fibre Channel address to each “remote” device foruse by the local devices in addressing the “remote” devices. Theselocally assigned addresses are only known by a switch within its FibreChannel address domain. Thus each switch maintains a set of locallyassigned Fibre Channel addresses which correspond to the globally knownIP Address/SoIP Port Number pairs defined in the SoIP Name Server.

According to one embodiment, due to the different address domains, eachswitch 235 intercepts Fibre Channel Extended Link Service requests andresponses which have Fibre Channel address information embedded in thepayload. Extended Link Service requests and responses are generatedinfrequently. Therefore, it is acceptable to redirect the Extended LinkService requests to the switch's management processor which makes anynecessary changes to the data frame. If an Extended Link Servicerequest/response has no addressing information embedded in the payload,the Management Processor simply retransmits the packet with nomodifications.

The IP Address and SoIP socket number assigned to a Fibre Channel orSCSI device are determined by the switch. The assignment of theseaddresses is implementation dependent. In a preferred embodiment, theSoIP socket number is assigned the device's local Fibre Channel address.In this embodiment, the switch obtains the local Fibre Channel addressdirectly from the received data frame. Alternatively, assignment of theSoIP socket number is based on an incrementing number that can be usedas an index into an address table.

In one embodiment, each device is assigned a unique IP address. However,this type of assignment may result in the use of a large number of IPaddresses. The use of a single IP address for each device also hasimplications for routing in the IP network. Therefore, in a preferredembodiment, IP addresses are assigned such that at least a subset of aswitch's attached devices share an IP address. For example, an IPaddress can be assigned to each switch port. Each device attached tothat switch port then shares the port's IP address. Thus, an attachedFibre Channel N_Port would have a unique IP address while the devices ona Fibre Channel arbitrated loop attached thereto would share an IPaddress.

According to one embodiment, Fibre Channel addresses are assignedglobally. Globally assigned Fibre Channel addresses provide the maximumcompatibility for “legacy” Fibre Channel devices. In this embodiment,the SoIP name server is responsible for managing the allocation ofGlobal Fibre Channel Addresses. A global Fibre Channel address space mayneed to be supported because in some cases Fibre Channel addresses maybe embedded within “third-party” SCSI commands. An example of such athird-party command is COPY. The COPY command instructs another deviceto copy data. The use of “third-party” commands is rare but when used,either the command would need to be modified for address compatibilityor the Fibre Channel addresses would need to be globally assigned.

With reference to the SoIP network shown in FIG. 12 a, an example thirdparty COPY command will be used to illustrate a problem that occurs withlocally assigned Fibre Channel addresses and third-party commands. Inthis example locally assigned Fibre Channel Addresses are also used asthe SoIP socket number. Each device has a unique IP address in thisexample.

FIG. 12 b shows the IP Address and SoIP socket number each device hasadvertised to the Name Server which identifies how the device isaddressed within the SoIP network. Each device is uniquely identified bythe combination of IP Address and SoIP socket number. Assume that theswitches 235.sub.3 and 235.sub.4 and Tape Library C are aware of everydevice in the system. Tape Library C would then have an address tablethat is the same as the name server's address table. Switches 235.sub.3and 235.sub.4 will have assigned local Fibre Channel addresses to eachdevice. FIG. 12 c illustrates the address table stored on switch235.sub.3 and FIG. 12 d illustrates the address table stored on switch235.sub.4. Because the Fibre Channel addresses are assigned locally, theaddress assignment is purely arbitrary.

Assume that Server A in local domain 1 sends a COPY command to Server Bin local domain 3 indicating that data is to be copied from RAID drive Bto Tape Library B, both of which are located in local domain 3. The COPYcommand will contain the addresses from Server A's perspective.Therefore, referring to FIG. 12 c, the command received by Server B isCOPY from Fibre Channel device 000500 (RAID drive B) to Fibre Channeldevice 000600 (Tape Library B). However, Server B will interpret theCOPY command using the address table of switch 235.sub.4 (FIG. 12 d) andassume it should copy data from RAID drive A to Tape Library A and notRAID drive B to Tape Library B. Thus, the wrong operation will beperformed. As another example, assume that Server B sends a command toServer A to copy from RAID drive A to Tape Library C. The command willbe COPY from Fibre Channel address 000500 to 009900 (the addresses arefrom the perspective of switch 235.sub.4). Server A will assume thecommand is to copy data from RAID drive B to a nonexistent devicebecause 009900 is not in the address table of switch 235.sub.4.

According to one embodiment, the switch gets around this problem byintercepting each third party command and modifying the embedded FibreChannel addresses to be compatible with the destination device. However,this requires that the source switch know the assignment of localaddresses in the destination switch. While it is possible for a switchto convert the third-party commands, alternative methods are preferred.

According to one alternative method, Fibre Channel addresses areglobally assigned for devices that are referenced by Fibre Channeladdress in third-party commands. The use of a Global Fibre Channeladdress allows third-party commands to be used with no modification, butsets the total number of devices possible in an SoIP network to the samemaximum as a Fibre Channel network. Only those devices that arereferenced in a third-party command require a global address, althoughall devices within an SoIP network can be assigned global addresses.

A Globally Assigned Fibre Channel address is preferably used as thedevice's SoIP socket number. This simplifies the conversion of “legacy”Fibre Channel data frames to SoIP compatible data frames. Therefore,globally assigning Fibre Channel addresses is equivalent to globallyassigning SoIP socket numbers.

Global SoIP socket number allocation is managed by the SoIP Name Server,which allocates Global SoIP socket numbers as requested from a pool offree socket numbers, and deallocates socket numbers (returns them to thefree pool) when they are no longer used. The assignment of Global SoIPsocket numbers for all devices in an SoIP network is the simplestsolution from a management standpoint because it does not requirespecifying the subset of devices that require a Global SoIP socketnumber (or alternatively, the devices that can use a local SoIP socketnumber).

Thus, all devices in an SoIP network either have a locally assigned SoIPsocket number or a globally assigned SoIP socket number. All SoIPcompatible devices and switches support both modes. Each device orswitch determines from the SoIP Name Server which mode is to besupported when it logs into the network. An SoIP Name Serverconfiguration parameter indicates the SoIP socket number allocationmode.

An environment that supports both local and global SoIP socket numbersis not required because it is expected that the need for global SoIPsocket numbers will be eliminated due to a new form of Third-Partycommand format, which embeds World Wide Names in the command instead ofthe Fibre Channel address. Because World Wide Names are unique, thedevice receiving the command is able to determine the appropriateaddress(es) to use from its point of view. One implementation of thisnew third-party command is the EXTENDED COPY command. Native SoIPdevices preferably use the version of third-party commands that embedWorld Wide Names in the command when SoIP socket numbers are locallyassigned.

In one embodiment, when SoIP socket numbers are assigned globally, therequester indicates the minimum number of socket numbers requested and a24-bit mask defining the boundary. For example, a 16-port switch mayrequest 4096 socket numbers with a bit mask of FFF000 (hex) indicatingthat the socket numbers should be allocated on a boundary where thelower 12 bits are 0. The switch would then allocate 256 socket numbersto each port (for support of an arbitrated loop). Allocation of socketnumbers on a specified boundary allows the switch to allocate socketnumbers that directly correlate to port numbers. In the above example,bits 11:8 would identify the port. Native SoIP devices preferablyallocate only one global SoIP socket number from the SoIP Name Server.

In one embodiment, the SoIP Name Server also includes a configurationparameter that selects “Maximum Fibre Channel Compatibility” mode whichonly has meaning for Global assignment of SoIP socket numbers. Devicesare able to query the Name server for the value of this parameter. Whenenabled, this mode specifies that global SoIP socket numbers are to beallocated in blocks of 65536 (on boundaries of 65536) to switches. Thismode is compatible with the existing Fibre Channel modes of addressallocation where the lower 8 bits identify the device, the middle 8 bitsidentify the port and the upper 8 bits identify the switch. SoIPswitches check for this mode and, if enabled, request 65536 socketnumbers when requesting global SoIP socket numbers. In this mode, NativeSoIP devices preferably allocate only one global SoIP socket number fromthe SoIP Name Server.

According to one embodiment, when operating in a Layer 2 network (e.g.,no IP routers), the frame format is modified to simplify theencapsulation logic. A Layer 2 network does not require the IP Header orthe UDP header. All frames are forwarded using the physical address(e.g. Ethernet MAC address). A switch then routes frames internallybased on the Layer 2 physical address (e.g. Ethernet MAC address)combined with the SoIP socket number. In essence, the Layer 2 physicaladdress replaces the IP address as a parameter in uniquely identifyingan SoIP device. FIG. 13 shows the frame format for an FCP frametransmitted on Ethernet. An Ethernet Type value 290 is definedspecifically for SoIP to allow a station receiving the frame todistinguish the frame from other frame types (e.g., IP). The IP and UDPheaders have been removed which reduces the frame overhead. An advantageis that the length and checksum fields in the UDP header no longer needto be generated. The generation of the IP and UDP headers introducesadditional latency for the frame transmission because the length andchecksum are located at the beginning of the frame. Therefore, it isnecessary to buffer the entire frame to determine the length andchecksum and write them into the header. For an Ethernet Layer 2 SoIPframe, it is only necessary to determine the amount of padding, if any,added at the end of the frame. The number of PAD bytes must be includedin the SoIP Header to allow the PAD bytes to be removed at the receivingstation. Since the padding is only required to satisfy a minimumEthernet frame size of 64 bytes, it is possible to complete the headergeneration after 64 bytes of the frame (or the entire frame) have beenreceived.

The Layer 2 frame format is similar to the Layer 3 frame format SoIPFrame conversion described above with reference to FIG. 6 with thefollowing differences:

a. The IP and UDP headers are no longer present.

b. The Ethernet Type value is different.

c. The CHEKSUM PAD field is replaced by the FC CRC field. The FC CRCfield is a 4-byte field containing the Fibre Channel CRC calculated overthe FCP header and payload. This field may be inserted by a source whena Fibre Channel data frame is encapsulated with no changes. Thus, theCRC received with the frame is still valid.

d. The CHECKSUM PAD flag is replaced by the FC CRC PRESENT flag. Thisbit indicates if the FC CRC field is present in the frame. Note that theCHECKSUM PAD field has no meaning since there is no need to calculate aUDP checksum.

e. The FRAME PAD LENGTH may have a non-zero value since the encapsulatedframe length may be less than the Ethernet minimum of 64.

The UDP Header contains a Destination Port field and a Source Portfield. The normal usage of these fields is to identify the softwareapplications that are communicating with each other. An applicationrequests a port number for use when sending a UDP “datagram”. This portnumber becomes the source port number for each UDP datagram sent by theapplication. When a UDP datagram is received, the destination portnumber is used by the UDP layer to determine the application to whichthe datagram will be forwarded. FIG. 14a illustrates “demultiplexing” ofUDP datagrams as is typical in the industry.

FIGS. 14 b and 14 c illustrate ways to add an SoIP layer according toembodiments of the present invention. FIG. 14 b illustrates framedemultiplexing when there is a single port number assigned to all SoIPdevices. Further demultiplexing is then performed using the SoIP socketnumber to determine the device. Routing data frames to applications isthen performed based on the FCP exchange numbers located in the FCPheader. FIG. 14 c illustrates a similar example, but with separate UDPport numbers assigned to each SoIP device. In this case, it is notnecessary to examine the SoIP socket number in order to forward the UDPdatagram. (The SoIP socket number and IP address must still uniquelyidentify the device). The choice of whether to use a single UDP portnumber for each SoIP device or one UDP port number for all devices isimplementation dependent.

The UDP demultiplexing examples illustrated in FIGS. 14 b and 14 c areoriented toward a server with one or more host bus adapters (where thehost bus adapters are the SoIP devices). A switch is generally lesscomplicated in the sense that data frames are forwarded to end devicesand the application layer does not have to be handled.

The addressing mechanisms described above allow software applications toappear as SoIP devices by registering with the name server using adifferent address. This opens up the possibility for applications toadvertise themselves in the name server for use by other applications.An example is a COPY manager that could be used by a higher level backupapplication.

According to one embodiment, each storage device, when it registers withthe name server, must include the UDP port number to use when sendingdata frames to the device. In a normal UDP application, the destinationport would save the source port number for use in sending a reply.However, this mechanism is not feasible for use with “legacy” FCswitches since it requires the switch to associate the source portnumbers with the exchange ID's. It is much simpler to require a storagedevice to always use the same UDP port number.

As a result, according to this embodiment, a storage device isidentified by 3 parameters in the name server database: IP Address, UDPPort Number, and SoIP socket number. An additional parameter required isthe physical address (e.g. Ethernet MAC address) which is determined inthe normal manner for IP networks. ARP (address resolution protocol) ispreferably used to learn the physical address to use for an IP address.The physical address to use can also be learned when a frame is receivedfrom a device. For example, the physical address can be learned when aPort Login request is received. The physical address may not be thephysical address of the actual device but the address of an IP router.

The SoIP Name Server (SNS) must have a UDP Port number that is known byall of the SoIP devices within an SoIP network since the port numbercannot be learned from another source. This could be a “well-known” portnumber or a registered port number. This approach is similar to a DomainName Server (DNS) that has a well-known port number of 53. Theassignment of “well-known” port numbers is done by the IANA (InternetAssigned Numbers Authority).

Routing within an IP network is affected by the choice of addressingmode which impacts the ability of switches and routers to determine whatconstitutes a “conversation”. A conversation is a set of data framesthat are related and which should arrive in order. However, it isassumed that conversations have no ordering relationship. In otherwords, the ordering of frames from different conversations can bechanged with no effect. For example, assume that frames for 3conversations (A, B and C) are transmitted in the following order (A1sent first):

A1 A2 B1 B2 B3 A3 B4 A4 A5 A6 A7 B5 B6 B7 C1 C2 C3 A8.

It is permissible for the frames to be received in any of the followingsequences (note that there are many more possible sequences that areacceptable): 1 A1 A2 A3 A4 A5 A6 A7 A8 B1 B2 B3 B4 B5 B6 B7 C1 C2 C3; A1A2 A3 A4 A5 A6 C1 C2 B1 B2 B3 B4 B5 B6 B7 C3 A7 A8; and C1 C2 A1 C3 A2B1 B2 A3 A4 A5 A6 B3 B4 B5 A7 A8 B6 B7.

In each of the above sequences, the frames for a particular conversationarrive in order with respect to each other, but out of order withrespect to frames from other conversations. The ability to identifydifferent conversations allows load balancing to be performed byallowing traffic to be routed on a conversation basis. Switches androuters can determine conversations based on several parameters within adata frame including Destination/Source addresses, IP Protocol, UDP/TCPPort Numbers, etc. The parameters actually used are dependent on theswitch/router implementation.

Storage traffic between the same two devices should be treated as asingle conversation. It is not acceptable for storage commands to bereceived out of order because there may be a relationship between thecommands (e.g. ordered queuing). Therefore, it is preferable to selectan addressing mechanism that makes a device unique to a switch/routerbut does not attempt to distinguish commands. Different IP addresses arean ideal choice for distinguishing devices since this method works withall switches and routers. When an IP address is shared, it is preferredthat the UDP Port Numbers be unique for the devices sharing the IPaddress. Thus, devices that share an IP address have the possibility tobe treated separately by switches and routers that classifyconversations based on UDP port numbers. It is understood that thediscussion of UDP Port Numbers above also applies to TCP Header PortNumbers when SoIP is implemented using TCP instead of UDP.

FIG. 15 is a high level block diagram which illustrates the basicarchitecture for a switch port that supports both Fibre Channel andGigabit Ethernet according to an embodiment of the present invention.The Fibre Channel and Gigabit Ethernet ports use the sameencoding/decoding method (8B/10B) with each port requiring aserializer/deserializer (SERDES) block for converting to/from the highspeed serial interface. Therefore, these two interfaces share the 8B/10Bblock 310 and SERDES block 315 in this embodiment as shown in FIG. 15.These two interface types differ in clock speed with Fibre Channeloperating at 1062.5 MHz and Gigabit Ethernet operating at 1250 MHz.Higher speed versions of these interfaces are being developed which willalso have a different clock speed. Therefore, a multiplexer 345 selectsthe clock used by the logic based on the port type. In addition, thesetwo interfaces share the switch fabric interface logic block 320 whichinterfaces with the switch fabric (including the management interface).The MAC blocks (blocks 325 and 330) implement the appropriate protocolstate machines for the interface (Fibre Channel or Gigabit Ethernet).The MAC blocks 325 and 330 convert received data into frames which areforwarded to the routing logic blocks 335 and 340, respectively. The MACblocks 325 and 330 also receive data frames from the routing logicblocks 335 and 340, respectively, which are then transmitted accordingto the interface's (Fibre Channel or Gigabit Ethernet) protocol. Routinglogic blocks 335 and 340 determine where each received frame should berouted based on addressing information within the frame. Routing logicblocks 335 and 340 also perform any modifications to the frames that arerequired. For example, a routing logic block will remove the SoIPencapsulation from a frame being forwarded to a Fibre Channel port. Therouting logic block then sends the frame to the switch fabric with anindication of the destination output ports. Egress data frames (framesfrom the switch fabric to the output port) are received by a routinglogic block and forwarded to the associated MAC. Additional processingmay be performed on the frame by the routing logic block before the MACreceives the frame. For example, Ethernet port routing logic block 340may convert a Fibre Channel frame into an SoIP frame.

According to another embodiment of the present invention as shown inFIG. 16, the two routing blocks of FIG. 15 are combined into a singlerouting logic block 350. This optimization is possible because therouting logic used by these two interfaces is very similar. In oneembodiment, routing logic block 350 includes logic blocks which aredependent on the port type and other blocks that are common to both porttypes. This optimization reduces the number of logic gates required onan ASIC. Routing block 350 determines where a frame is routed based onaddressing information within the data frame. This function is known asaddress resolution and is performed for both Fibre Channel and GigabitEthernet data frames. Therefore, address resolution logic can be sharedby these two port interfaces though it is necessary for the routinglogic to select different data based on the port type. The logic withinRouting Logic block 350 can be implemented as hard coded logic or as aprogrammable method using a network processor, which is designedspecifically for processing packets and which can be programmed to routeeither Fibre Channel frames or Ethernet frames. Therefore, the routinglogic hardware can be shared by using different network processorsoftware. In one embodiment, routing logic block 350 also includes aninput and output FIFO memory which is shared by the two port interfaces.Additional logic which can be shared include statistics registers andcontrol registers. Statistics registers are used to count the number offrames received, frames transmitted, bytes received, bytes transmitted,etc. A common set of statistics registers can be used. These registersare modified by control signals from each MAC. Control registersdetermine the operating mode of each MAC. A common set of statistics andcontrol registers reduces the logic required to implement the registersand for interfacing with an external control source such as a switchmanagement CPU.

In another embodiment as shown in FIG. 17, the low-level port interfacelogic (e.g., FC MAC block 325 and Ethernet MAC block 330) is combinedinto a single MAC block 360. One problem with this approach, however, isthat these two logic blocks have little in common. In addition, it ispossible to purchase proprietary blocks which implement Gigabit EthernetMAC and Fibre Channel Port Interface logic. Combining these two blockswould severely hinder the use of these proprietary blocks.

According to another embodiment of the present invention as shown inFIG. 18, a Field Programmable Gate Array (FPGA) 370 is used to selectthe interface protocol supported by the port. The FPGA configurationloaded would be based on the port type. In this embodiment, separateFPGA code is developed for the Fibre Channel and Gigabit Ethernetinterfaces. Thus, the FPGA logic can be optimized for the particularinterface. A single hardware design supports both interfaces, withsoftware determining the FPGA code to be downloaded based on the porttype.

A common port must also deal with the physical interface external to anASIC. As is well known, such an interface may include, for example, acopper, multi-mode fiber or single-mode fiber interface. Also, thecomponents are not necessarily the same between Fibre Channel andEthernet. According to an embodiment of the present invention as shownin FIG. 19, a Gigabit Interface Converter (GBIC) 380 is provided toallow a user to select the desired physical interface. A GBIC is astandardized module which has a common form factor and electricalinterface and allows any of the many physical interfaces to beinstalled. GBIC modules are available from many vendors (e.g. HP, AMP,Molex, etc.) and support all of the standard Fibre Channel and GigabitEthernet physical interfaces. FIG. 19 shows a block diagram of a commonFC/Gigabit Ethernet port interface (e.g., as shown in FIGS. 15, 16, 17and 18) combined with a GBIC interface according to this embodiment. TheASIC connects to a GBIC connector 385 which allows the user to changeGBIC modules. Thus, the user can select the media type by installing theappropriate GBIC 380.

GBIC modules typically contain a serial EEROM whose contents can be readto determine the type of module (e.g. Fibre Channel, Gigabit Ethernet,Infiniband, Copper, Multi-mode, Single-mode, etc.). The GBIC can thusindicate the type of interface, e.g., FC or GE or Infiniband, to use.However, it is possible for the GBIC to support multiple interfaces, forexample both FC and GE. Therefore, in one embodiment, the port interfacetype is user switchable/configurable, and in another embodiment the typeof the link interface is automatically determined through addedintelligence, for example, through a “handshake”.

According to another embodiment of the present invention, an SoIPintelligent network interface card (NIC) 400 is provided as shown inFIG. 20. NIC card 400 is able to send and receive both IP and SoIPtraffic. In either case, NIC card 400 has the intelligence to determinethe type of traffic and direct it accordingly.

The host 410 may issue both storage commands and network commands to NICcard 400 through the PCI interface 420. These commands are sent with aspecified address which is used to direct the commands to either theDirect Path or the Storage Traffic Engine. Storage commands are issuedvia the SCSI Command Set, and Network commands are issued via Winsockand/or TCP/IP.

NIC card 400 directs storage commands to the Storage Traffic Engine 430based on the specified address. Storage Traffic Engine 430 handles theexchange management and sequence management for the duration of the SCSIoperation. SCSI operations are then carried out via SoIP and transmittedto the network 470 via a media access controller (MAC) block 450, whichin one embodiment is a Gigabit Ethernet MAC. NIC card 400 directsnon-SoIP traffic to the Direct Path 440 based on the specified address.The Direct Path 440 processes the commands and transmits the specifiedpackets to network 470 via block 450. When receiving data from network470 via MAC 450, NIC 400 demultiplexes the traffic and directs itaccordingly. Storage traffic received as SoIP is sent to storage trafficblock 430. Non-SoIP traffic is sent directly to the host via direct path440.

The multiplexer block 460 handles arbitration for the output path whenboth Direct Path 440 and Storage Traffic Engine 430 simultaneously sendtraffic to MAC 450. For traffic received from network 470 by MAC 450,Mux block 460 demultiplexes the traffic and sends it accordingly toeither Direct Path 440 or Storage Traffic Engine 430.

While the invention has been described by way of example and in terms ofthe specific embodiments, it is to be understood that the invention isnot limited to the disclosed embodiments. To the contrary, it isintended to cover various modifications and similar arrangements aswould be apparent to those skilled in the art. Therefore, the scope ofthe appended claims should be accorded the broadest interpretation so asto encompass all such modifications and similar arrangements.

1. A network device configured to intercept a frame having a buffer tobuffer receive data field size and being transmitted to a destination ona network, adjust the buffer to buffer receive data field size of theintercepted frame, and route the modified frame to the destination onthe network.
 2. A device according to claim 1, wherein the interceptedframe is a node login frame or a node login response frame.
 3. A deviceaccording to claim 1, wherein the buffer to buffer receive data fieldsize is adjusted to allow Fibre Channel Protocol (FCP) data frames tofit into an IP packet that can be transmitted across the network withoutbeing fragmented.
 4. A device according to claim 3, wherein the networkis an ethernet network.
 5. A device according to claim 1, wherein thedevice is configured to perform maximum transmission unit (MTU)discovery to determine a size that does not result in fragmentation ofIP packets in the network, and the buffer to buffer receive data fieldsize is adjusted to the size determined by MTU discovery.
 6. A methodfor limiting frame size, comprising: intercepting a frame having abuffer to buffer receive data field size and being transmitted to adestination a network, adjusting the buffer to buffer receive data fieldsize of the intercepted frame, and routing the modified frame to thedestination on the network.
 7. A method according to claim 6, whereinthe intercepted frame is a node login frame or a node login responseframe.
 8. A method according to claim 7, wherein the buffer to bufferreceive data field size is adjusted to allow Fibre Channel Protocol(FCP) data frames to fit into an IP packet that can be transmittedacross the network without being fragmented.
 9. A method according toclaim 8, wherein the network is an ethernet network.
 10. A methodaccording to claim 6, further comprising performing maximum transmissionunit (MTU) discovery to determine a size that does not result infragmentation of IP packets in the network, and adjusting the buffer tobuffer receive data field size to the size determined by MTU discovery.